copy NearCacheEntry values as-if they had been materialized from cache #16
Conversation
|
@zspitzer any chance we can get some traction on this? |
|
I've asked @michaeloffner to review any chance of adding some tests? |
|
It looks like a day or two to get the current test suite running and add a test for this. We can find time for that but probably not until later this year. |
|
@zspitzer We've signed off on a day or so of work to get some tests in. Once that's done we're hopeful this can get merged in as otherwise we will need to fork this and build our own extension or use Ortus'. I think there is at least one other dev in the community who has done that so it might be worth looking to see whether there is interest in recruiting additional community members to help out with this extension (if it is indeed an official Lucee extension) or if it's more 'something the folks at LAS needed and helpfully decided to release but otherwise don't have time to maintain' -- either way is fine but it'd help us to know how you all look at it! Thanks as always! |
…all" adds hook to inject thread delays for testing purposes
With goal being not sharing live object refs to the underlying "to-be-cached" objects across NearCacheEntry objects fixes test introduced in prior commit resolves lucee#13
davidAtInleague
force-pushed
the
copy-near-cache
branch
from
2a94799 to
410fad9
Compare
yes there is a test now; introduced in 0f7d5c5, where the problem is reproduced and so the test fails. The fix is introduced in the subsequent commit and the test turns green. |
|
I can't reproduce the failure against 5.4 locally, so maybe some additional as-yet-to-be-addressed race condition? The failing test appears to be |
Goal here being to not share live object refs to the underlying "to-be-cached" objects across NearCacheEntry objects
resolves #13